© BUNDESREPUBLIK 
D E UTS CH LAND 




• iJJIi.M .1 l-^i^i, l,J IMJI || (j, t : HI H fjj |l <H ,1 Hi li! !! II JJ Mill 

© Offenlegungsschrift © , nt as 
® DE 41 31 380 A 1 



G 06 F 9/45 



DEUTSCHES 
PATENTAMT 



© Aktenzeichen: 
© Anmeldetag: 
© Offenlegungstag: 



P41 31 380.1 
20. 9.91 
25. 3.93 



CO 
CO 

LU 

a 



(7l) Anmefder: 

Siemens AG, 8000 Munchen, DE 



® Erfinder: 

Meyer, Walter, Dipl.-lng.; Rothe, Oliver, Dipl.-Math. 
8000 Munchen, DE; KneiSI, Franz, Dr., 8500 
Nurnberg, DE; Hubmann, Hans, Dipl.-lng., 8524 
Neunkirchen, DE; BeB, Rudiger, 8510 Furth, DE 



(g) Verfahren zur Adaption einer objektorientierten Appiikation 

®^ Es ^ ird bei einer objektorientierten Appiikation beim 
Comp,l.eren der Source* der Appiikation ein Aufberettungs- 
verfahren. beim Binden ein Konfigurationsverfahren, sowie 
berm Ablauf ein Kommunikationsverfahren angewendet zum 
Aufrufen von Methoden fur Objekte. Bei einer Anderung 
etner Systemkonfiguration ist eine Adaption der Sourcen 
nicht erforderiich. Dies gilt auch bei einer Erweiterung der 
objektorientierten Appiikation. 
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V500: LINKVERFAHREN 



V60Q: ABLAUF 
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Beschreibung 

Die Erfindung betrifft ein Verfahren zur Adaption einer objektorientierten Applikation, so daB diese auf 
mehrere Betriebssystemprozesse verteilbar ist 

5 Objektorientierte Applikationen sind mittels einer objektorientierten Programmierung realisierbar. Ein ob- 
jektorientiertes System besteht nicht nur aus Funktionen oder Prozeduren, welche einander aufrufen, etwa bei 
einer Programmierung mit den Programmiersprachen Fortran, Pascal, C, sondern es sind auch Objekte vorgese- 
hen, die durch den Austausch von Nachrichten miteinander kommunizieren. Ein Beispiel fur eine objektorien- 
tierte Programmiersprache ist die Programmiersprache C + 4-, welche durch eine Erweiterung der weit verbrei- 

10 teten Programmiersprache C entstanden ist In der Programmiersprache C+ + werden KJassen von Objekten 
durch Typdefinitionen vereinbart Die Objekte geiten als Variablen eines KJassentyps und werden als Instanzen 
der Klasse bezeichnet Jedes Objekt hat Instanzvariable als einen Satz von Daten. Auf die Instanzvariablen kann 
nur mittels bestimmter Funktioiien zugegriffen werden, die in der jeweiligen Klassendefinition festgelegt wer- 
den. Diese der Klasse zugeordneten Zugriffsfunktionen heiBen Methoden der Klasse. In der Programmierspra- 

is che C+ + ist das Senden einer Nachricht an ein Objekt gleichbedeutend mit dem Aufruf einer Methode fur 
dieses Objekt. Die Programmiersprache C++ unterstutzt die Vererbung von Klassen. Die Instanzvariablen und 
die Methoden einer Klasse konnen von einer abgeleiteten Klasse durch Vererbung Qbernommen werden. Es 
konnen Methoden der Basisklasse mit dem Schlusselwort virtual deklariert werden, so daB diese Methoden in 
einer abgeleiteten Klasse redefinierbar sind Objekte sind durch Zeiger referenzierbar sowie dynamisch erzeug- 

20 bar, so daB erst zur Laufzeit entscheidbar ist, welche Implementierung einer Methode tatsachlich ausgefuhrt 
wird. In der Programmiersprache C+ + sind Applikationen auf genau einen ProzeB im Sinne des Betriebssy- 
stems begrenzt Bei einer realen Anwendung kann es zu Problemen fuhren, wenn die Applikation eine bestimm- 
te GroBe iiberschreitet da Betriebssystemprozesse nur eine begrenzte GroBe annehmen konnen. Somit ist ohne 
zusatzliche MaBnahmen auch die GroBe einer C++ Applikation begrenzt Aus einigen Anwendungsbereichen, 

25 insbesondere der Automatisienjngstechnik sowie der Telekommunikation, bestehen Anforderungen, welche 
eine Aufteilung der Applikation auf mehrere unabhangige, getrennt ausfuhrbare und ladbare Betriebssystem- 
prozesse veriangen. Eine derartige Aufteilung auf mehrere Betriebssystemprozesse, also keine light-weight 
Prozesse, ist mit den Sprachmittein von C+ + aileine nicht formulierbar. Eine derartige Aufteilung einer 
Applikation auf mehrere Betriebssystemprozesse bedingt eine wesentliche Erweiterung der Funktionalitat 

30 indem Mechanismen des Betriebssystems genutzt werden sollen, die die Kommunikation zwischen den Betriebs- 
systemprozessen herstellen. Es ist denkbar, daB explizit vom Programmierer in die Applikation Aufrufe fur eine 
InterprozeBkommunikation (IPC) eingefugt werden, sowie daB eigene IPC-Klassen verwendet werden. Der 
Softwareersteller hat indiesem Fall die Programmierung der IPC-Mechanismen selbst vorzunehmen. Die 
Aufteilung der Applikation auf die einzelnen Betriebssystemprozesse ist fest im Sourceprogramm eincodiert Bei 

35 einer erforderlichen Anderung der ProzeBaufteilung sind vom Programmierer die Sourceprogramme zu modifi- 
zieren und erneut zu compilieren. 

Es ist Aufgabe der Erfindung, ein Verfahren anzugeben, zur Adaption einer objektorientierten Applikation, 
welche auf mehrere Betriebssystemprozesse verteilbar ist so daB insbesondere der Programmierer die zu 
compilierenden Sourcen der Applikation nicht selbst modifizieren muB. 

40 Diese Aufgabe ist geiost bei einem Verfahren zur Adaption einer objektorientierten Applikation, welche auf 
mehrere Betriebssystemprozesse verteilbar ist 

a) mit einem Aufbereitungsverfahren zur Codesubstitution von zu compilierenden Sourcen der Applikation 
gemafl einem Stub-Konzept 

45 b) mit einem Konfiguraticnsverfahren zur Verteilung von Instanzen der Applikation als Objekte oder 

Stub-Objekte fur zu bindende Module aus compilierten Sourcen der Applikation, 

c) mit einem beim Ablaui vorgesehenen Kommunikationsverfahren zum Aufrufen von Methoden fur 
Objekte der Applikation mit Hilfe einer Stub-Methode. 
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Ausfuhrbar ist ein bevorzugtes Verfahren mit zumindest einem von foigenden Verf ahrensschritten des Aufbe- 
reitungsverfahrens: 



d) es wird eine Klassendeklaration der Sourcen analysiert fur eine Vergabe von Methoden-Identifikationen, 
so daB Methoden von verwendeten Klassen der Applikation eindeutig mittels der Methoden-Identifikation 

55 identifizierbar sind, 

e) es werden die Klassen der Applikation mit einer generischen Methode erganzt mittels welcher jene 
Methode beim Ablauf lokal aufrufbar ist welche durch einen Parameter der generischen Methode in Form 
der Methoden-Identifikation identifiziert wird, 

f) es werden Basisklassen der Applikation urn eine redifinierbar deklarierte Stub-Methode erganzt 

60 g) es wird jeder von bei einem Ablauf vorgesehenen Aufrufen von einer Methode fur ein Objekt der 

Klassen ersetzt durch einen beim Ablauf vorgesehenen Aufruf der Stub-Methode f Qr das Objekt 

- so daB bei einem positiiven Ergebnis des Aufrufs der Stub-Methode fur das Objekt beim Ablauf ein 
Aufruf vorgesehen ist zu einem prozeBubergreifenden Versenden von einer Nachricht durch welche in 
einem Remote-ProzeB der Aufruf der Methode des Objektes veraniaflt wird, indem die Methoden- Idenufi- 

65 kation in der Nachricht enthalten ist 

— sowie daB bei einem negativen Ergebnis des Aufrufs der Stub-Methode fur das Objekt beim Ablauf im 
Lokal-ProzeB der Aufruf der Methode des Objektes erfolgt 

h) es werden HUfsdefinitionen fur Methoden generiert so daB zu jeder Methode der Applikation zumindest 
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— ihr KJassenname, 

— ihr Methodenname, 

— ihre Parametertypen, 

— ihr Parameterstring fiir ein Einpacken sowie Auspacken von Parameters sowie, 

— ihre Methoden : Identifikation definiert sind. 

Ausfuhrbar ist ein weiteres bevorzugtes Verfahren mit zumindest einem von folgenden Verfahrensschritten 
des Konfigurationsverfahrens: 

k) es wird eine bestimmte Systemkonfiguration der Applikation anaiysiert fur eine Verteilung der Objekte 
als die Instanzen der Applikation auf die Betriebssystemprozesse der Applikation, 

m) es wird eine generische Instanziemngsfunktion generiert, mittels welcher beim Ablauf ein neues Objekt 
der Applikation instanzierbar ist, 

— mit einer lokalen Instanzierung im Lokal-ProzeB bei einem gemaB der Systemkonfiguration lokal zu 
instanzierenden Objekt, so daB das negative Ergebnis beim Aufruf der Stub-Methode im Lokal-ProzeB fur 
dieses lokal-instanzierte Objekt vorgesehen ist, 

— sowie mit einer remoten Instanzierung bei einem gemaB der Systemkonfiguration remote zu instanzie- 
renden Objekt, indem im Lokal-ProzeB ein prozeBubergreifender AnstoB vorgesehen ist zur Instanzierung 
dieses remote zu instanzierenden Objektes im Remote-ProzeB. sowie mit einer lokalen Instanzierung fur 
ein zu diesem Objekt vorgesehenes lokales Stub-Objekt, dessen Stub-Methode im Lokal-ProzeB redefiniert 
wird, so daB das positive Ergebnis beim Aufruf der Stub-Methode fur dieses als Stub-Objekt lokal instan- 
zierte Objekt im Lokal-ProzeB vorgesehen ist, 

n) es wird eine generische Loschfunktion generiert, mittels welcher beim Ablauf die Instanzierung von 
einem der Objekte der Applikation Ioschbar ist, 

— mit einem lokalen Loschen im Lokal-ProzeB bei einem gemaB der Systemkonfiguration iokal-instanzier- 
ten Objekt, 

— sowie mit einem remoten Loschen bei einem gemaB der Systemkonfiguration remote instanzierten 
Objekt, indem im Lokal-ProzeB ein prozeBubergreifender AnstoB vorgesehen ist zum Loschen dieses 
remote-instanzierten Objektes im Remote-ProzeB, sowie ein lokales Loschen von dem zu diesem Objekt 
vorgesehenen lokalen Stub-Objekt, 

p) es werden Runfiles erzeugt, indem zu den Modulen bei jeder ladbaren Einheit Module, 

— fur die Instanziemngsfunktion, 

— fur die Loschfunktion sowie 

— fur die Hilfsdefinitionen fur die Methoden der Applikation dazugebunden werden. 

Ausfuhrbar ist ein weiteres bevorzugtes Verfahren mit zumindest einem von folgenden Verfahrensschritten 
des Kommunikationsverfahrens: 

r) es wird die Stub-Methode fur eines der Objekte lokal aufgerufen, sowie im Falle des negativen Ergebnis- 
ses erfolgt ein lokaler Methodenaufruf fur das Objekt, 

s) es wird im Falle des positiven Ergebnisses fur den lokalen Aufruf der Stub-Methode fur das Objekt, aus 
den gebundenen Hilfsdefinitionen, 

— die Methoden-Identifikation, 

— das remote-instanzierte Objekt sowie 

— Methodenparameter ermittelt, 

t) es wird anhand des Parameterstrings eine Nachricht verpackt im Lokal-ProzeB, 
u) es wird die Nachricht im Remote-ProzeB empfangen, 

v) es wird im Remote-ProzeB nach dem Auspacken der Parameter das lokal instanzierte Objekt ermittelt, 
w) es wird mittels der generischen Methode anhand der Methoden-Identifikation der Aufruf der dadurch 
identifizierten Methode ausgefiihrt. 

Der Erfindung liegt die Idee zugrunde, daB die zu compilierenden Sourcen der Applikation in einem Aufberei- 
tungsverfahren insbesondere mittels eines Praprozessors modifizierbar sind, so daB durch Codesubstitution 
Methodenaufrufe ersetzbar sind durch Codesequenzen, mittels derer beim Ablauf entscheidbar ist, ob ein 
prozeBubergreifendes Versenden einer Nachricht erforderlich ist, oder ob ein lokaler Aufruf erfolgen soIL Dies 
ist realisierbar, indem Hilfsdefinitionen fiir die Methoden generiert werden, so daB durch den Einsatz dieser 
spezielten Dateien eine Sicherung der Konsistenz des Systems bei der Applikation gewahrleistet ist Dies ist 
weiterhin erzielbar, jndem ein Stub-Konzept angewendet wird, bei welchem Stub-Methoden und Stub-Objekte 
verwendet werden. Weiterhin ist dies erzielbar, indem eine Instanzierungsfunktion sowie eine Loschfunktion in 
einem Runtime-System eingesetzt wird. Dies ist weiterhin erzielbar, indem bei einem prozeBubergreifenden 
Kommunikationsverfahren beim Ablauf insbesondere eine generische Methode eingesetzt wird, von welcher 
anhand einer Methoden-Identifikation der dadurch identifizierte Methodenaufruf ausfuhrbar ist 

In einer vorteilhaften Weise braucht der Programmierer die Sourcen nicht selbst modifizieren. 

In einer vorteilhaften Weise kann der Programmierer die Sourcen der Applikation beispielsweise mit den 
Sprachmitteln der Programmiersprache C -h + ersteilen. 

In einer vorteilhaften Weise ist mittels der Codesubstitution beim Aufbereitungsverfahren nur eine einmaiige 
Modifikation der Sourcen mit deren anschlieBender Compilierung ausreichend. Bei einer Anderung der System- 
konfiguration, also bei einer Anderung der Verteilung der Applikation auf mehrere Betriebssystemprozesse, ist 
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eine Anderung der Sourcen der Applikation nicht erforderlich, so daB auch eine neue Compilierung nicht 
erforderlich ist 

In einer vorteilhaften Weise wird mitteis der Hilfsdefinitionen fur eine bestimmte Systemkonfiguration die 
Konsistenz des Gesamtsystems der objektorientierten Applikation sichergestellt 

Die Erfindung wird anhand der Figuren, in welchen Ausf uhrungsbeispiele enthalten sind f naher erlautert 

Die Fig. 1 zeigt ein erfindungsgemaBes Verfahren zur Adaption einer objektorientierten Applikation, welche 
auf mehrere Betriebssystemprozesse verteilbar ist 

Die Fig. 2 zeigt ein anderes Venahren zur Adaption einer objektorientierten Applikation, welche auf mehrere 
Betriebsprozesse verteilbar ist 

Die Fig. 3 zeigt ein Aufbereiturigsverfahren fur das erfindungsgemaBe Verfahren zur Adaption einer objekt- 
orientierten Applikation, welche auf mehrere Betriebssystemprozesse verteilbar ist. 

Die Fig. 4 zeigt ein Konfigurationsverfahren fur das erfindungsgemaBe Verfahren zur Adaption einer objekt- 
orientierten Applikation, welche auf mehrere Betriebssystemprozesse verteilbar ist. 

Die Fig. 5 zeigt ein prozeBubergreifendes Kommunikationsverfahren fur das erfindungsgemaBe Verfahren 
zur Adaption einer objektorientierten Applikation, welche auf mehrere Betriebssystemprozesse verteilbar ist 

Die Fig. 6 zeigt einen Methodenaufruf. 

Die Fig. 7 zeigt eine Codesequenz nach einer Codesubstitution des Methodenaufrufs. 

Die Fig. 8 zeigt einen prozeBubergreifenden Sendeaufruf fur eine Nachricht als einen Teil der Codesequenz. 
Die Fig. 9 zeigt einen Aufruf einer Stub-Methode als ein Teil der Codesequenz. 

Wie die Fig. 1 zeigt, besteht ein Ausfuhrungsbeispiel fur das erfindungsgemaBe Verfahren zur Adaption einer 
objektorientierten Applikation, weiche auf mehrere Betriebssystemprozesse verteilbar ist, aus den Verfahrens- 
schritten V100, V200, V300, V400, V500, V600, sowie V700. 

- Es wird der Verfahrensschritt VI 00 ausgefuhrt Vom Programmierer werden die zu compilierenden Sourcen 
der Applikation erstellt 

Es wird der Verfahrensschritt V200 ausgefuhrt Fur die zu compilierenden erstellten Sourcen der Applikation 
wird ein Aufbereitungsverfahren durchgefuhrt Dabei kann ein Praprozessor vorgesehen sein zur Durchfuhrung 
des Aufbereitungsverfahrens. Es werden Klassendeklarationen der Sourcen der Applikation analysiert Es 
werden Methoden-Identifikationen aufbereitet Die Kiassen der Applikation werden um die generische Metho- 
de erganzt Es werden die Methodenaufrufe in den Sourcen der Applikation modifiziert indem mitteis Codesub- 
stution Codesequenzen eingesetzt werden anstelle der Methodenaufrufe. Es werden Hilfsdefinitionen fur die 
Methoden der Applikation generiert 

Es wird der Verfahrensschritt V300 ausgefuhrt Die vom Aufbereitungsverfahren modifizierten Sourcen 
werden compiliert 

Es folgt der Verfahrensschritt V400. Es wird ein Konfigurationsverfahren ausgefuhrt. Es wird eine Konfigura- 
tionsdatei analysiert Es wird eine Instanzierungsfunktion generiert Es wird eine Loschfunktion generiert Es 
werden Hilfsdefinitionen fur die Methoden der Applikation mitgebunden. Es werden Runfiles erzeugt 

Es folgt der Verfahrensschritt V500. Es wird ein Linkverf ahren ausgefuhrt Es werden ablauffahige Phasen der 
Betriebssystemprozesse gebundeit 

Es folgt der Verfahrensschritt V600. Es wird ein Ablauf der Betriebssystemprozesse der Applikation ausge- 
fuhrt 

Es folgt der Verfahrensschritt V700. Es wird untersucht ob eine Konfigurationsanderung erforderlich ist Falls 
dies der Fall ist folgt der Verfahrensschritt V400. GemaB der geanderten Systemkonfiguration wird das Konfi- 
gurationsverfahren erneut durchgefuhrt Danach folgt der Verfahrensschritt V500, bei welchem das Linkverfah- 
ren erneut durchgefuhrt wird Danach folgt der Verfahrensschritt V600, bei welchem der Ablauf der Applikation 
gemaB der geanderten Systemkonfiguration erfolgt 

Wie die Fig. 2 zeigt besteht ein Ausfuhrungsbeispiel fur ein anderes Verfahren zur Adaption einer objekt- 
orientierten Applikation aus den Verfahrensschritten V101, V301, V501.V601.V70l sowie V801. 

Es wird der Verfahrensschritt VI 01 ausgefuhrt Von einem Programmierer werden die Sourcen der Applika- 
tion erstellt Je nach Aufteilung der Applikation auf mehrere Betriebssystemprozesse werden vom Programmie- 
rer explizit die Aufrufe fur eine prozeBQbergreifende Kommunikation in den Sourcen der Applikation eingetra- 
gen. 

Es folgt der Verfahrensschritt V301. Die vom Programmierer erstellten Sourcen werden compiliert 
Es folgt der Verfahrensschritt V501. Fur die compilierten Sourcen der Applikation wird das Linkverf ahren 
durchgefuhrt 

Es folgt der Verfahrensschritt V601. Es erfolgt der Ablauf der Applikation. 

Es folgt der Verfahrensschritt V701. Es wird gepruft ob eine Konfigurationsanderung erforderlich ist Falls 
dies der Fall ist folgt der Verfahrensschritt V801. GemaB einer neuen Systemkonfiguration werden vom 
Programmierer die Sourcen der Applikation modifiziert indem gemaB der neuen Verteilung der Applikation auf 
einzelne Betriebssystemprozesse in den Sourcen explizit Aufrufe fur eine prozeBQbergreifende Kommunikation 
eingefugt werden. Danach folgt erneut der Verfahrensschritt V301, bei welchem die soeben modifizierten 
Sourcen compiliert werden. 

Danach folgt der Verfahrensschritt V501. bei welchem das Linkverfahren erneut durchgefuhrt wird. 

Danach folgt der Verfahrensschritt V601, bei welchem der Ablauf der Applikauon gemaB der neuen System- 
konfiguration erfolgt 

Wie die Fig. 3 zeigt, besteht ein Ausfuhrungsbeispiel fur das Aufbereitungsverfahren des Verfahrensschrittes 
V200 aus den Verfahrensschritten V210. V220, V230, V235, V240 sowie V250. 

Es wird der Verfahrensschritt V210 ausgefuhrt Es wird eine Klassendeklaration der Sourcen der Applikauon 
analysiert fur eine Vergabe von Methoden-Identifikationen, so daB die Methoden von den verwendeten Kiassen 



der Applikation systemweit eindeutig mittels der Methoden-Identifikation identifizierbar sind 

Es folgt der Verfahrensschritt V220. Es wird eine Protokoll-Informations-Datei aufbereitet in welcher Hilfs- 
definitionen fur die Methoden der Applikation enthaiten sind, so daB zu jeder Methode der Applikation 
zumindest ihr Klassenname, ihr Methodenname, ihre Parametertypen. ihr Parameterstring fur ein Einpacken 
sowie Auspacken von Parametern sowie ihre Methoden-Identifikation definiert sind. 

Es folgt der Verfahrensschritt V230. Es werden die KJassen der Applikation um die generische Methode 
erganzt Mittels der generischen Methode ist anhand der Methoden-Identifikation ein Aufruf der dadurch 
identifizierten Methode ausftihrbar. 

Es folgt der Verfahrensschritt V235. Es werden die Basisklassen der Applikation um eine redefinierbar 
deklarierte Stub-Methode erganzt 

Es folgt der Verfahrensschritt V240. Es werden in den Sourcen die Methodenaufrufe modifiziert mittels einer 
Codesubstitution. 

Es folgt der Verfahrensschritt V250. In einer Hilfsdefinitionsdatei werden die Hilfsdefinitionen fur die Metho- 
den generiert und aufbereitet 

Wie die Fig. 4 zeigt, besteht ein Ausfuhrungsbeispiel fiir das Konfigurationsverfahren des Verfahrensschrittes 
V400 aus den Verfahrensschritten V410, V420, V430, V440 sowie V450. 

Es wird der Verfahrensschritt V410 ausgefiihrt. Es wird eine bestimmte Systemkonfiguration der Applikation 
anhand einer Konfigurationsdatei analysiert mittels welcher eine Verteilung der Objekte der Applikation auf die 
Betriebssystemprozesse der Applikation vorgenommen wird. 

Es folgt der Verfahrensschritt V420. Es wird eine generische Instanzierungsfunktion generiert, mittels welcher 
beim Ablauf die Objekte der Applikation instanzierbar sind 

Es folgt der Verfahrensschritt V430. Es wird eine generische Loschfunktion generiert, mittels welcher beim 
Ablauf die Instanzierung der Objekte der Applikation loschbar ist 

Es- folgt der Verfahrensschritt V440. Es werden Module fur die Hilfsdefinitionen fur die Methoden der 
Applikation gebunden. 

Es folgt der Verfahrensschritt V450. Es werden Runfiles erzeugt, indem zu den Modulen bei jeder ladbaren 
Einheit Module fiir die Instanzierungsfunktion, fur die Loschfunktion sowie fiir die Hilfsdefinitionen fur die 
Methoden der Applikation dazugebunden werden. 

Wie die Fig. 5 zeigt besteht als ein Teil des Verfahrensschrittes V600 ein Ausfuhrungsbeispiel von einem 
Verfahrensschritt V605 fur einen Ablauf zum Aufrufen einer Methode fur ein Objekt der Applikation aus den 
Verfahrensschritten V610 bis V680. 

In einem Lokal-ProzeB wird der Verfahrensschritt V610 ausgefuhrt. Es wird ein lokaler Adressat ermittelt 
Dieser ist im Falle eines lokalen Objektes die Instanz selbst Im Falle eines remoten Objektes ist der lokale 
Adressat das zugehorige Stub-Objekt 

Es folgt der Verfahrensschritt V620. Es wird fur den lokalen Adressaten die Stub-Methode aufgerufen. 

Es folgt der Verfahrensschritt V621. Es wird uberprtift, ob das Ergebnis beim Aufruf der Stub-Methode fur den 
lokalen Adressaten positiv ist. 

Falls das Ergebnis negativ ist, folgt der Verfahrensschritt V680, und es erfolgt der Aufruf der Methode fur den 
lokalen Adressaten, welcher in diesem Fall das instanzierte lokale Objekt isL 

Bei einem positiven Ergebnis folgt der Verfahrensschritt V640. Fur die aufzurufende Methode wird deren 
Methoden-Identifikation ermittelt 

Es folgt der Verfahrensschritt V641. Es wird der remote Adressat ermittelt, welcher in diesem Fall das remote 
instanzierte Objekt ist 

Es folgt der Verfahrensschritt V642. Es werden die Parameter fur den remoten Aufruf der Methode verpackt 
Es folgt der Verfahrensschritt V670. Es erfolgt eine InterprozeBkommunikation (IPC) zwischen dem Lokal- 
ProzeB und dem Remote- ProzeB. 

Im Remote-ProzeB folgt der Verfahrensschritt V650. Es werden die Parameter fur den Aufruf der Methode 
ausgepackt 

Es folgt der Verfahrensschritt V651. Es wird der lokale Adressat im Remote-ProzeB ermittelt. Dieser ist in 
diesem Fall das im Remote-ProzeB instanzierte Objekt 

Es folgt der Verfahrensschritt V652. Es erfolgt ein Aufruf der generischen Methode, bei welcher mittels der 
Methoden-Identifikation die aufzurufende Methode ermittelt wird 

Es folgt der Verfahrensschritt V660. Es erfolgt der Aufruf der Methode fur das im Remote-ProzeB instanzierte 
Objekt 

Mittels der InterprozeBkommunikation des Verfahrensschrittes V670 wird nach dem Remote-ProzeB der 
Lokal-ProzeB fortgesetzt 

Wie die Fig. 6 zeigt besteht ein Ausfuhrungsbeispiel fur einen lokalen Aufruf einer Methode fGr ein Objekt 
aus einem Objektpointer, einem Methodennamen sowie aus Parametern. Der Objektpointer bildet dabei eine 
Referenz auf das Objekt an welches eine Nachricht gesendet wird Der Methodenname bildet dabei eine 
Bezeichnung fiir die Nachricht Die Parameter bilden dabei einen Parameterteil fiir die Nachricht 

GemaB vereinbarter Notation gilt beispielsweise folgende Schreibweise: 

< Objektpointer > — * < Methodenname > (< Parameter > ) 

< Objektpointer > : Referenz auf das Objekt an das die Nachricht gesendet wird 

< Methodenname > : Bezeichnung der Nachricht 

< Parameter > : Parameterteil fur die Nachricht 
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Beispielsweise bei der Programmiersprache C + + ist deren Nachrichtenmechamsmus » >"V^^[ 
die Adressierung von Objekten innerhalb eines Betriebssystemprozesses unterstutzt wird. Appiikationen, , wel 

Nachrichtenmechanismus. Diese Erweiterung des Nachnchtenmechanamu , sol\ mch «^ e ™ "^T^ 
der Programmiersprache erfolgen, da auf diese Weise eme PortabiUtat ei »S^™£ ^ PortabUiS^eSleistet 
Nachrichtenmechanismus soil in einer solchen Weise vorgenommen werden daB 3^,^^"^^™^ 
ist Zusatzlich zu dem in der Programmiersprache verankerten prozeBlokalM 

noch ein Mechanismus fur einen prozefiubergreifenden Nachnchtenaustausch in Form e ne '^i^koni 
munikation (IPC) bereitgestellt werden. Dabei sollen kerne neuen S P r ^" n e ^ e ?J^^^ a ^ n e S 
Compilererweiterung nicht erforderlich ist. Von einem Praprozessor soli m e mem Aufbereitung ivertahren mr 
die zu compilierende 8 n Sourcen der Applikation ein derartiger Methodenaufruf Ji^JjgS 
ersetzt werden durch eine Codesequenz. in welcher zusatzhch .mpl.zue ^^^^^^^ 
Nachnchtenaustausch (IPC) enthalten sind. Mittels dieser Codesequenz soil sowohl der proze Blokale Nachnch 
K^utudTaJ. auch ein erweiterter Nachnchtenaustausch uber ProzeBgrenzen h.nweg erlaubt werden. 

Wie die Fig. 7 zeigt, besteht ein Ausfuhrungsbeispiel fur eine derart.ge Codesequenz aus einem lokalen Aufruf 
einer Stub-Methode* Vstub. so daB bei einem positiven Ergebnis dieses Aufrufs e.ne fur die ^^P™"^^ 
nikation (IPC) erweiterte Form des Aufrufs vorgesehen ist, sowie daB be. emern nega 

Methodenaufruf vorgesehen ist. welcher gleich ist dem in der Fig. 6 dargestellten Methodenaufruf. welcher 
durch die in der Fig. 7 dargestellte Codesequenz bei der Codesubstitution ersetzt wird. 
GemaB vereinbarter Notation gilt beispielsweise folgende Schreibwe.se: 

_((<Objektpointer>-*VstubO)?(SX SEND((_CSXobj*) 
<Objektpointer>. <Methoden-ID>, <Parameterstring>, < Parameter>): 
( <Objektpointer> — < Methodenname > (< Parameter > )) 

< Methoden-ID> : Methoden- Identifikation zur systemweit eindeutigen Identifizierung von Methoden 

von Klassen der Applikation 

< Parameterstring > : Zeichenstring zur Identifizierung von Parametern beim Einpacken sowie Auspacken 

von Parametern 

Dabei dient die Methoden-Identifikation zur systemweit eindeutigen Identifizierung ; vo n ; ™ r ^": 
sen der Applikation. Es ist ein Parameterstring vorgesehen, welcher in Form ernes Zeichenstnngs zur Identifizie 
rung von Parametern beim Einpacken sowie Auspacken von Parametern dient. *„*„.*- fr ir die 

Wie die F.g.8 zeigt, enthalt ein Ausfuhrungsbeispiel einer derart erwe.terten Form . des ' 
InterprozeBkommunikation (IPC) einen Aufruf zum prozeBubergreifenden Versenden der Nachr.cht, e.nen 
Objektpointer, eine Methodenldentifikation. einen Parameterstring sowie Parameter. 

GemaB vereinbarter Notation gilt beispielsweise folgende Schreibweise: 

(SX_SEND((_CSXobj*) < Objektpointer >. <Methoden-ID>, < Parameterstring >, < Parameter >) 

Ob dieser Aufruf tatsachlich aktiviert wird. wird zur Laufzeit entschieden durch eine Auswertung des Ergeb- 
nisses, welches als eine Abfrage mittels des Aufrufs der Stub-Methode ermittelt wtrd. 

Wie die Fig. 9 zeigt, besteht ein Ausfuhrungsbeispiel fur einen Aufruf der Stub-Methode aus etnem Objekt 
pointer sowie aus dem Method«:nnamen Vstub. 

GemaB vereinbarter Notation gilt beispielsweise folgende Schreibweise: 

(< Objektpointer > Vstub()) 

Vor dem Versenden der Nac.hricht gemaB des Methodennamens an das referenzierte Objekt wird jedesmal 
^^bS^S^M^bJ^utna stattfinden soil, oder ob ein mittels der ■« W<^"™£*£ 
tic-7 PC) erweiterter Aufruf clurchgefQhrt wird. Im Falle eines IPCAufrufes kommt die Funktion SX-SEND 
^T^Tto mit den gceignften Parametern zu versorgen isu Diese Parameterversorgung soli bei der 
Codesubstitution automatisiert vom Praprozessor vorgenommen werden. automatisierbar 

In einer vorteilhaften Weise erfolgt die Codesubstitution nach einfachen Regeln. so daB diese automatisierbar 
ist, und beispielsweise von einem Tool durchgefuhrt werden kann. a;* -,*™*™ Cndeteile substi- 

Zusammen mit der Codesubstitution fur die Nachrichtenaufrufe sollen auch noch diejen«e<i ™£ 
tuiert werden, welche die Instanzierung von Klassen sow.e das Entfernen von Objekten aus dem System 

be DTe f Emscheidung. welche Form des Nachrichtenmechanismus jeweils zum •^£"^^^2?^ 
kales Versenden der Nachricht oder ein prozeBubergreifendes Vereendend *r 

Programmes getroffen werden, und zwar in Abhangigkett von einer aktuellen .S^^™« U *^j;^™ 
objektorientierten Softwaresynemen dynamisch veranderbar ist. ^^^^^^^^^^ 
sol diese Abfrage sehr schnell vonstatten gehen und deshalb prozeBlokal erfolgen In jedern ^f^JPJt 
zeB soil ieweils eine Instanz existieren, welche daruber Auskunft geben kann, ob sich ein adressiertes ODjeM 
V^^^^t^^tv^^ des Nachrichtensenders befindet, oder falls es in einem anderen 
^bSa^^B eSSt^ine Wegeinformation bereitstellen zur Ermoglichung der Adressierung. Dies 
soil mittels eines Stub-KonzepKes erfolgen. 
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Bei einem derartigen Stub-Konzept sollen in einer verteilten Applikation in denjenigen Betriebssystempro- 
zessen. welche nicht selbst ein reales Objekt enthalten, Stellvertreter-Objekte ais Stub-Objekte ansteile der 
realen Objekte vorhanden sein. Diese Stub-Objekte stehen dann im Falle einer Anforderung an das reale Objekt 
ais Ansprechpartner lokal zur Verfiigung und konnen entweder dessen Aufgaben direkt iibernehmen oder die 
gelorderte Dienstleistung an das reale Objekt weitervermitteln. Diese Stub-Objekte sollen sich gegeniiber den 
anderen Objektenexaktwie die realen Objekte verhalten. 

Eine derartige Aufgabe oder eine mogliche Dienstleistung ist beispielsweise die Auskunft dariiber ob es sich 
bei einem bestimmten Objekt um die Instanz selbst handelt oder um das Stub-Objekt Falls es sich da'bei urn die 
Instanz selbst handelt, kann die Nachricht in der beispielsweise bei der Programmiersprache C+ + ublichen 
Form direkt an das adressierte Objekt gesendet werden. Anderenfalls soli das Stub-Objekt alle notwendieen 
Inforrnationen dariiber bereitstellen. um die entsprechende Anforderung an das reale Objekt weiterzuleiten. Im 
Bedarfsfal kann jedes Objekt, einschlieBlich der Stub-Objekte. dariiber Auskunft geben, ob es selbst ein 
u Vj V" r nichL Zu diesem Zweck wird eine Methode, die Stub-Methode VstuW) ais virtuelle 
Methode in der Basisklasse aller Applikationsklassen bereitgestellt Durch den Vererbungsmechanismus erhal- 
ten i alle Objekte der Applikation automatisch die Fahigkeit, Auskunft dariiber zu geben, ob sie Stub-Obiekte 
sind oder reale Objekte. Es wird in der Basisklasse aller Applikationsklassen die Stub-Methode bereiteestellt 
welche im Falle einer Aktivierung ein negatives Ergebnis lieferu Die Stub-Methode ist redefinierbar zu deklarie- 
™:!" de c '? die Stub-Methode beispielsweise bei der Programmiersprache C+ + das Schltisselwort virtual 
He ern £ nK 'u TIi™? Stu ^ M * thode redefiniert, so daB sie ein positives Ergebnis liefert. Demnach 
Met ern Stub-Objekte auf die Anfrage Vstub() gemaB der Stub-Methode ein anderes Ergebnis ais die Nicht-Stub- 
uojekte, bei welchen eine Defauit-Implementierung zum Tragen kommt. 

H^ m rIK SyStemk0 !l fig, ^^; ad ^? n, a,S ° eine Aufteilun 8 der Objekte auf Betriebssystemprozesse. braucht erst nach 
dem Ubersetzen der Quellprogramme festgelegt werden. Erst zur Laufzeit soil entschieden werden, welcher 
Nachrichtenmechanismus jeweils zum Tragen kommt. Dies gilt auch fur den Vorgang der Instanzierung von 
K. assen sowie das Entfernen von Objekten aus dem laufenden System. Dies kann nicht statisch vom Compiler 
eriedigt werden, sondern soli vom Laufzeitsystem ausgefuhrt werden. 

Ebenso wie bei der Codesubstitution fur die Nachrichtenaufrufe werden auch die Aufrufe NEW und DELETE 
in der Source vom Praprozessor durch die Funktionen SX-NEWobj ais Instanzierungsfunktion und SX- DE- 
LETE ais Loschfunktion ersetzt. Diese Funktionen werden im Laufzeitsystem ausgefuhrt. Diese Funktionen 
werden zu jeder ladbaren Einheit dazugebunden. Sie inkorporieren die Inforrnationen dariiber. ob ein Objekt 
tokal oder remote indistanziert oder geldscht werden soil. Bei der Instanzierung wird demzufoige entweder der 
Operator NEW beispielsweise bei der Programmiersprache C++ verwendet. oder es wird iiber die Interpro- 
uS 0m TJ 11 u at,0n 6 i n " an ^ erun g d « Objektes in einem anderen Betriebssystemprozefl angestoBen und 
lokal w,rd dabei nur em Stub-Objekt erzeugt. Die Ldschfunktion entscheidet zur Laufzeit. ob das Objekt. auf das 
s ' e _f n S e ^ ndet wird, ein Stub-Objekt oder ein reales Objekt ist. Abhangig davon wird entweder der Operator 
DELETE beispielsweise bei der Programmiersprache C+ + verwendet oder es wird Qber die InterprozeBkom- 
rrn?° n u , f n d ? Objektes in einem anderen BetriebssystemprozeB angestoBen und lokal wird das 
Mub-Objekt geloscht Die Implementierung der Instanzierungsfunktion und der Loschfunktion wird aufgrund 
von Angaben in einer Konfigurationsdatei generiert. 

Beim prozeBubergreifenden Kommunikationsmechanismus gehen Methodenaufrufe, also auch Aufrufe von 
i^onstrukturen und Destruktoren, uber ProzeBgrenzen hinweg, so daB diese Aufrufe in versendbare Daten 
inTn^ 3 r^ S ' v? a u e ' J Werden die Methoden de «- verwendeten KJassen durch Methoden-Identifikationen 
aentifiziert. Diese Methoden-Identifikationen werden beispielsweise mittels einer Protokoll-Informations-Da- 
tei systemweit eindeutig vergeben und mittels der generischen Methode ausgewertet, welche jedes Objekt 
oesitzt. Die ProtokoII-Informations-Datei bildet eine systemweite Datenbasis uber Methoden und ihre Metho- 
aen-identifikationen. Diese wird bei jeder Codesubstitution ausgewertet und soweit erforderlich vervollstandigt. 
uie Krotokoll-Informations-Partei enthalt fur jede Methode der Applikation folgende Daten: 

- KJassenname, 

- Methodenname, 

- Typen der Parameter der Methode (diese Angabe ist notwendig. da beispielsweise in der Programmier- 
spracfte C+ + Methoden nicht ailem aufgrund von KJassennamen und Methodennamen, sondern erst 
durch die Parametertypen eindeutig identifiziert werden konnen), 

- Parameterstring (beispielsweise verwendet fur das Einpacken sowie Auspacken der Parameter) 

- Methoden-Identifikation. 

r, Bei ^ Codesubstitution wird d 'e Definition jeder verwendeten Klasse um die generische Methode erweitert 
Diese bildet die Methoden-Identifikationen auf lokale Methodenaufrufe ab. Jeder Methoden-Aufruf aus einem 
anderen ProzeB fQhrt im EmpfangerprozeB zunachst zu einem Aufruf der generischen Methode mit der Metho- 
den-Identifikation ais Parameter. 

Beim prozeBQbergreifenden Versenden der Nachricht werden die Parameter des Methodenaufrufs in einer 
Datenstruktur verpackt und verschickt. Die Funktionen SX-SEND und die generische Methode sind fur das 
u P *?au S ° Wie Aus P acken der Parameter vorgesehen. Dazu werden der Funktion SX-SEND Inforrnationen 
uber Methodenparameter codiert ubergeben, beispielsweise in Form eines Strings. Dieser Informationsstring, 
also der Parameterstring, wird bei der Codesubstitution ebenfalls vom PrSprozessor aufbereitet. 

Somit wird bei einer objektorientierten Applikation beim CompiUeren der Applikation ein Aufbereitungsver- 
fahren. beim Binden ein Konfigurationsverfahren sowie beim Ablauf ein Kommunikationsverfahren angewen- 
det zum Aufrufen von Methoden fur Objekte. Bei einer Anderung einer Systemkonfiguration ist eine Adaption 
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der Sourcen nicht erforderlich. Dies gilt auch bei einer Erweiterung der objektorientierten Applikation. 

Patentanspriiche 

1. Verfahren zur Adaption einer objektorientierten Applikation, welche auf mehrere Betriebssystemprozes- 
se verteilbar ist, 

a) mit einem Aufbereitungsverfahren (V200) zur Codesubstitution von zu compilierenden Sourcen der 
Applikation, gemaB einem Stub-Konzept, 

b) mit einem Konfigurationsverfahren (V400) zur Verteiiung von Instanzen der Applikation ais Objek- 
te oder Stub-Objekte fur zu bindende Module aus compilierten Sourcen der Applikation, 

c) mit einem beim Ablauf vorgesehenen Kommunikationsverfahren (V605) zum Aufrufen von Metho- 
den fur Objekte der Applikation mit Hilfe einer Stub-Methode. 

2. Verfahren nach Anspruch 1, mit zumindest einem von folgenden Verfahrensschritten des Aufbereitungs- 
verfahrens (V200): 

d) es wird eine Klassendeklaration der Sourcen analysiert (V210) filr eine Vergabe von Methoden-Iden- 
tifikationen t so daB Methoden von verwendeten KJassen der Applikation eindeutig mittels der Metho- 
den-Identifikation identifizierbar sind, 

e) es werden die KJassen der Applikation mit einer generischen Methode erganzt (V230), mittels 
welcher jene Methode beim Ablauf lokai aufrufbar ist, welche durch einen Parameter der generischen 
Methode in Form der Methoden-Identifikation identifiziert wird, 

f) es werden Basiskk.ssen der Applikation um eine redifinterbar deklarierte Stub-Methode erganzt 
(V235), 

g) es wird jeder von bei einem Ablauf vorgesehenen Aufrufen von einer Methode fur ein Objekt der 
KJassen ersetzt (V240) durch einen beim Ablauf vorgesehenen Aufruf der Stub-Methode fur das 
Objekt, 

— so daB bei einem positiven Ergebnis des Aufrufs der Stub-Methode fur das Objekt beim Ablauf ein 
Aufruf vorgesehen ist zu einem prozeBubergreifenden Versenden von einer Nachricht, durch welche in 
einem Remote-ProzeB der Aufruf der Methode des Objektes veranlaBt wird, indem die Methodenlden- 
tifikation in der Nachricht enthalten ist, 

— sowie daB bei einem negativen Ergebnis des Aufrufs der Stub-Methode fur das Objekt beim Ablauf 
im Lokal-ProzeB der Aufruf der Methode des Objektes erfolgt, 

h) es werden Hilfsdefinitionen fur Methoden generiert (250), so daB zu jeder Methode der Applikation 
zumindest 

— ihr Klassenname, 

— ihr Methodenname, 

— ihre Parametertypen, 

— ihr Parameterstring fur ein Einpacken sowie Auspacken von Parametern, sowie 

— ihre Methoden-Identifikation definiert sind. 

3. Verfahren nach Anspruch 2 mit zumindest einem von folgenden Verfahrensschritten des Konfigurations- 
verfahrens (V400): 

k) es wird eine bestimmte Systemkonfiguration der Applikation analysiert (V410) zur Verteiiung der 
Objekte ais die Instanzen der Applikation auf die Betriebssystemprozesse der Applikation, 
m) es wird eine generische Instanzierungsfunktion generiert (V420), mittels welcher beim Ablauf ein 
neues Objekt der Applikation instanzierbar ist, 

— mit einer lokalen Instanzierung im Lokal-ProzeB bei einem gemaB der Systemkonfiguration lokai zu 
instanzierenden Objekt, so daB das negative Ergebnis beim Aufruf der Stub-Methode im Lokal-ProzeB 
fur dieses lokal-Instanzierte Objekt vorgesehen ist, 

— sowie mit einer remoten Instanzierung bei einem gemaB der Systemkonfiguration remote zu 
instanzierenden Objekt, indem im Lokal-ProzeB ein prozeBubergreifender AnstoB vorgesehen ist zur 
Instanzierung dieses remote zu instanzierenden Objektes im Remote-ProzeB, sowie mit einer lokalen 
Instanzierung fur ein zu diesem Objekt vorgesehenes lokales Stub-Objekt, dessen Stub-Methode im 
Lokal-ProzeB redefiniert wird, so daB das positive Ergebnis beim Aufruf der Stub-Methode fur dieses 
ais Stub-Objekt lokai instanzierte Objekt im Lokal-ProzeB vorgesehen ist, 

n) es wird eine generische Loschfunktion generiert (V430), mittels welcher beim Ablauf die Instanzie- 
rung von einem der Objekte der Applikation loschbar ist, 

— mit einem lokalen L<6schen im Lokal-ProzeB bei einem gemaB der Systemkonfiguration lokal-instan- 
zierten Objekt, 

— sowie mit einem remoten Loschen bei einem gemaB der Systemkonfiguration remote instanzierten 
Objekt, indem im Lokal-ProzeB ein prozeBubergreifender AnstoB vorgesehen ist zum Loschen dieses 
remote-instanzierten Objektes im Remote-ProzeB, sowie ein lokales Loschen von dem zu diesem 
Objekt vorgesehenen iokaien Stub-Objekt, 

p) es werden Runfiles erzeugt(V450), indem zu den Modulen bei jeder ladbaren Einheit Module 

— fflrdie Instanzierungsfunktion, 

— fur die Loschfunktion sowie 

— fur die Hilfsdefinitionen fur die Methoden der Applikation dazugebunden werden. 

4. Verfahren nach Anspruch 3 mit zumindest einem von folgenden Verfahrensschritten des Kommunika- 
tionsverfahrens (V605): 

r) es wird die Stub-Methode fur eines der Objekte lokai auf gerufen (V620), sowie im Falle des negativen 




41 31 380 Al 



P 



Ergebnisses erfolgt ein lokaler Methodenaufruf fQr das Objekt (V680) t 

s) es wird im Falle des positiven Ergebnisses fur den iokalen Aufruf der Stub-Methode f 

ausden gebundenen Hiifsdefinitionen 

- die Methoden-Identifikation(V640), 

- das remote-instanzierte Objekt (V641)sowie - 

- Methodenparameter ermittelt, 

t) es wird anhand des Parameterstrings eine Nachricht verpackt im Lokal-ProzeB (V642) 
u) es wird die Nachricht im Remote-ProzeB empfangen (V670), 
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FIG7 

(«Objektpointer>-> Ystubl )) 7 (SX_SEND (LCSXobj*) 
<Objektpointer>, < Methoden- ID>; <Parameterstring>,<l^rameter»: 
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